A common programming paradigm is to compile code at runtime. A just-in-time (JIT) compiler is an example of such as system. Other systems that compile at runtime include continuous compilation systems that immediately begin execution in an interpretive state but compile the code over time and continuously optimize the compilation. With JIT compilers, as classes are loaded into the virtual machine (VM), the method pointers in the virtual method table are replaced with pointers to the JIT compiler. Then, the first time each method is called, the JIT compiler is invoked to compile the method. The pointer in the virtual method table is then patched to point to the native-code version of the method so that future calls to the method will jump to the native-code. These JIT compiler systems have the advantage of transmitting code to a target machine in an intermediate language (IL) such as JAVA bytecodes, common language runtime (CLR) instructions, and so on. The compiler is designed to convert the IL into instructions executable by the native processor. As a result, the same IL instructions can be sent to computers having different native processors and execute nonetheless on the target processor.
Such portable code has become popular. In this model, the code that is generated follows a set of rules and the execution engine (at a remote site) can verify that the code follows these rules. One of these rules is that the code should be verifiable, i.e. it is possible to assert the types of the objects on stack at all times during the execution of the code. This rule is a direct by-product of the Object Oriented Programming language constraints where the generated code has type information, unlike native code. Hence typically all Object Oriented Programming languages would have a concept of verifiability of generated code.
With the introduction of a variety of different virtual machines (VM), it is sometimes necessary for one execution engine to run code that is written for another virtual machine. However, the constraints imposed by one virtual machine may differ from another. In some versions of VM (like JAVA™ VM), local variables used in method implementation can be reused once the local variable goes out of scope i.e. the same variable number in different contexts could mean different types in the compiled code and could hence refer to different local variables in the source code. Also the compiled code need not have the information about the types of a local variable in different scopes. In some other VM, having more restrictive constraints, a local variable can be used to represent only one type and may not be reused.